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"An Electr onic Transaction System' 
Field of the Invention 



The present invention relates to an electronic transaction system. The system is 
particularly suited for facilitating the sale of services and/or goods in electronic 
5 format (such as software). 

Background Art 

The following discussion of the background of the invention is intended to facilitate 
an understanding of the invention. However, it should be appreciated that the 
discussion is not an acknowledgement or admission that any of the material 
10 referred to was published, known or part of the common general knowledge of the 
person skilled in the art in any jurisdiction as at the priority date of the application. 

Retailing of any good or service often requires the input of multiple parties. This 
input can be difficult to co-ordinate, particularly in situations where the input of one 
party, or even the need to contact that party for their input, is dependent on the 
15 input of another party. In situations where the retailed service or good is 
distributed over an electronic network, this problem is further exacerbated by the 
common expectation that such services or goods can be provided immediately. 

Accordingly, it is an object of the present invention to provide an electronic 
transaction system that is customisable in a manner that simplifies the task of co- 
20 ordinating input from multiple parties over an electronic network. 

A yet further problem with electronic transaction systems is the need for the 
electronic transaction system to integrate with the existing, pervasive Electronic 
Funds Transfer at Point of Sale ("EFTPOS") infrastructure. This poses problems 
as the EFTPOS infrastructure: 
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• typically comprises transaction devices that include only an 
embedded payment applications because of their limited memory 
capacity; and 

• are highly regulated, such that any changes to an application that 
5 uses the EFTPOS infrastructure must be recertified - a considerably 

costly process for the application owner. 

One prior method of overcoming this problem has been to integrate the 
transaction system with the embedded payment application. However this 
solut.cn requires the transaction acquirer or processor to modify their main switch 
10 to accommodate transaction transactions as well as payment transactions. Such 
modifications are expensive and time-consuming. 

It is therefore an optional, subsidiary, object of the present invention to provide an 
electronic transaction system that utilises the existing EFTPOS infrastructure 
whrte overcoming, or at least partially alleviating, one or more of the 
1 5 aforementioned problems associated with the existing EFTPOS infrastructure. 

Disclosure of the Invention 

Throughout the specification, unless the context requires otherwise, the word 
■comprise- or variations such as "comprises" or "comprising", will be understood to 
.mp.y the inc.usion of a stated integer or group of integers but not the exclusion of 
20 any other integer or group of integers. 

Further, the term "e.ectronic service" is to be understood as meaning any service 
where the transaction constituting offer and acceptance of the service is 
conducted over an electronic medium. 

In accordance with a first aspect of the invention there is provided an e.ectronic 
25 transaction system comprising: 



a host server; 
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at least one service provider system; and 
a content management system, 

where the content management system provides content in the form of details of 
electronic goods and/or services able to be transacted by the electronic 
transaction system to the at least one transaction device and where, upon the at 
least one transaction device issuing a client request to the host server for one or 
more of the electronic goods and/or services detailed, the host server operates to 
generate a client response in reply to the client request and in generating the 
chent response, where necessary, issuing a service request to the at least one 
serv.ce provider system and receiving a service response from the at least one 
service provider. 

Ideally, the electronic payment system further comprises a matrix recording a set 
of perm.ssions and/or constraints applicable to the electronic transaction system 
and where the content management system references the matrix in determining 
the content to be provided to each transaction device of the at least one 
transaction device to ensure that the set of permissions and/or constraints are 
complied with. Preferab.y, the matrix inc.udes at least one of the foHowing 
dimensions: 

20 a transaction device dimension; 

an electronic good or service dimension; and 

a merchant dimension, 

each dimension operable to recording information in respect of the transaction 
dev.ce, electronic good or service or merchant, as appropriate, that may affect 
25 the content to be provided by the content management system 
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The host server may also determine whether the client request complies with the 
set of permissions and/or constraints recorded in the matrix and references the 
matrix in generating a client response to ensure that the set of permissions and/or 
constraints are complied with. 

5 In a further preferred embodiment, each transaction device of the at least one 
transaction device receives a set of unique identifiers from the host server each 
unique identifier representing a component of the content, the transaction device 
operable to check the set of unique identifiers against content already provided 
and request content having unique identifiers not already provided from the 
10 content management system. The transaction device may further operate to 
d,scard components of the content having a unique identifier not included in the 
set of unique identifiers received from the host , server. Ideally, the unique 
.dentifier consists of a file name and at least one of the following: a version 
number; an error check value. 

15 Alternatively, upon creation of content using the content management system the 
content management system operates to provide the content to each transaction 
dev,ce of the at least one transaction device. In this manner, almost "real-time" 
download of content to transaction devices can be attained. 

The content preferably includes, in respect of each electronic service and/or good 
20 able to be transacted; at least one of the following: 

a description; 

a graphic to represent the electronic service or good; 
details of acceptable payment methods; 

details of acceptable validation or data entry mechanisms; and/or 

details of any document to be provided when the service response 
confirms a service request was successful. 
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The content may also include: 

a menu structure for navigating the electronic services and goods able to 
be transacted; and 

details of any security mechanisms implemented to control access to any 
5 restricted portions of the menu structure; 

Each , transaction device of the a, leas, one transaction device may receive a 
scheduled time for transmission of content from the content management system 
each transaction device operable to request the se, of unique identifiers from the 
host server on the scheduled time. 

10 Preferably, the host server operates to generate a Cent response in reply to the 
Cent request by reference to a process mode,, the process mode, conceptually 
eompnsrng a series of steps and links, the arrangement of one or more links in 
respect of a firs, step representing a second step to process on the firs, step 
resolvrng ,o a predetermined resul, in a se, of predetermined results. The se, of 

15 predetermined results, ideally, are a set of Boolean values and a fail result 

The electronic transaction system may also include at leas, one channe, grouping 
each channe, grouping associated with a, toast one transaction device where 
content provided to each transaction device o, a channe, grouping is the same as 

20 7 en ', PrOVided '° 6a0h ° ther ,ranSaC,ton dSViCe ' he Same ' 9-"Pi"9. 

20 At east one relationship may also be included in the e,ec.ron,c transaln 

system, each relationship recording details for facilitating communication between 

he host server and either a transaction device or a service provider system, using 

their respective native languages and communication protocols. 

In a ye, preferred embodiment, the electronic transaction system also includes an 
eto«ron,c inventory, the electronic inventory operable to provide an electronic 
good to the host server on request. The request from the host server for an 
electronic good may include a goods identifier, the electronic inventory operable 
to provrde an electronic good having a contending goods identifier in response 
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to the request. To combat potential fraud, on return of an electronic good to the 
electronic inventory, the electronic good is not able to be provided in response to 
a request from the host server for a predetermined period of time. The electronic 
good may be a serial number to be provided in redeeming an electronic service 
5 able to be transacted. 

The electronic transaction system may be operable to issue both synchronous 
and asynchronous service and client requests. Asynchronous service requests 
and asynchronous client requests include a correlation key and any response to 
the asynchronous service request or asynchronous client request, as appropriate, 
10 includes the correlation key. As asynchronous service requests can cause 
confusion for the host server, the host server may be operable to distinguish 
between a service response and a client request by reference to the correlation 
key and/or type. 

Preferably, each service request, service response, client request and client 
1 5 response is communicated via at least one message bus. The message bus may 
use a publish/subscribe mechanism of communication. 

Ideally, the transaction device includes at least one payment application. Using 
an intermediate router having a dedicated connection to the host server and to a 
payments host, the transaction device may forward a service request issued by a 
20 transaction device to the host server and forward a payment request issued by the 
payment application of the transaction device to the payments host. 

In a potential alternate processing method, the transaction device issues an 
authorisation request to the intermediate router for forwarding to the payments 
host and receives an authorisation reply from the payments host via the 
intermediate router and where, if so authorised, the transaction device thereafter 
issues a service request to the host server via the intermediate router and, upon 
receiving a service response indicating that the service request was successful, 
issuing a payment request to the payments host via the intermediate router. 
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The transaction device may , urther include removab|e wm 

reccing one or more of the fol.ov.ng: a receipt; an electronic good; details of the 

client request; details of the client response. 

The host server may operate to confirm the identity and/or capacity of the 

ZcTr, tha ' iSSUSd ^ «■ ' «° - the 

exceeded 9 T ^ " CW °' »» '~" **• 

is exceeded, ignore the client request. 

in accordance with a second aspect ofthe prasen, invention there is a host server 
10 invention" " ° ^ to < he flrsl ^ «* •» 

in . accordance with a <hi ra aspect of the presen, invent™ .here is a .ransadon 
device for use ,n an electronic transaction system acceding to .he firs, aspect of 
the invention. H 

15 ! e r rdanCe 3 ' 0Urth "»"* °' ' he ~ - a me,hod of 

15 performs an electronic transaction comprising the steps of: 

providing comen. ,„ the form of de(ai|s Qf ^ ^ 

able to be transacted to at least one transaction device; 

receiving a client reques, for one or more of .he electronic goods and/or 
services detailed from a transaction device; 

20 generating a Cent response in reply to the client re quest ^ where 

riecessary. includes issuing a service request to at least one service 
provider system and receiving a service rasponse from t» at least one 
service provider. 

Idea„y, t(1e me.hod also includes .he step of referencing a matrix recording a set 
25 of perm,ss,ons and/or cons«rain,s .o ensure .ha. ,he contenl ,o be proviL ,o 
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each transaction device complies with the recorded set of permissions and/or 
constraints. 

Preferably, the method also includes the steps of determining whether the client 
request complies with the set of permissions and/or constraints recorded in the 
matrix and the step of generating a client response includes the sub-step of 
referencing the matrix to ensure that the set of permissions and/or constraints are 
complied with. 

The method may also include the step of sending a set of unique identifiers to 
each transaction device, each unique identifier representing a component of the 
10 content, and the step of transmitting any content having unique identifiers not 
already provided to the transaction device upon request by the transaction device 
Additionally, the method includes the step of receiving a request for the set of 
un.que identifiers from each transaction device at each transaction device's 
scheduled time. 

15 Preferably, the step of generating a client response includes the substep of 
executing a process model, the process model conceptually comprising a series 
of steps and links, the arrangement of one or more links in respect of a first step 
representing a second step to process on the first step resolving to a 
predetermined result in a set of predetermined results. 

20 The method also includes the step of associating each transaction device with at 
leat one channel grouping, the content provided to each transaction device of a 
channel grouping being the same as content provided to every other transaction 
device in the same channel grouping. 

Ideally, the method includes the step of recording details for facilitating 
25 communication between the host server and each transaction device and the host 
server and each service provider system to form a set of relationships and the 
step of using the appropriate relationship in the set of relationships to facilitate 
communication between the host server and transaction device or service 
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provider system, as appropriate, in their respective native ianguages and 
communication protocols. 

The p d may also inc , ude , he s(eps of , ssu . ng a ^ 

, tory for an eiectronic good and receiving an eiectronic good from the 
5 electronic inventory. 

Preferably, the method aiso incudes the step of distinguishing between a service 
response and a ciien, rogues, by reference to a correction Key in the service 
response and/or type. service 

10 ™ h0d r a ' S0 ' nClUde S,SP -.vice requests, service 

10 responses, Cent requests and Cent responses by way of a, ieast one message 
bus using a publish/subscribe mechanism of communication. 

Zr o y ; t 'he e ,~ inc,udes ,he steps of c ~ 9 ,he «-* 

tanon^ ,H r *** ' hat iSSUSd C " em re " UeSt and ,ne *P °' 

.gnonng the Cent request if the identity of the transaction device can no, be 

15 ^rmedor,hecapaci,yoftt,e,ransac, to ndev.ceisexceeded. 
Brief Description of the Drawings 

The invention wi„ now be described wi,h reference ,o me foiiowing drawings, of 



Figure 1 is a schematic represented Can electronic transaction system. 

20 Figure 2 is a conceptua, representation of a process mode, step, with M 
attachments, as used in the electronic ,ransac,ion system o, Figure 1 . 

Figure 3 is an illustration o, process flows o, a host server as illustrated in Figure 

Figure 4 is a diagram o, a transaction sequence used by a transaction device 
25 when communicauon witt, ,he host server as Wustrated in Figure ,. 
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Figure 5 is a schematic of the components of a multi-purpose transaction device 
for use in the electronic Transaction system of Figure 1 . 

Best Mode(s) for Carrying Out the Invention 

In accordance with the present invention there is an electronic transaction system 
5 10. In the electronic transaction system 10 being described, and as shown in 
Figure 1, the electronic transaction system 10 comprises: 



10 



a host server 12; 



at least one transaction device 14; 

at least one service provider system 16; 



databases 18; 



process designer 20; 



content management system 22; 

scheduler 24; 

channels matrix 26; 

schedule management module 28; 

merchant reporting module 30; 

management module 32; 

accounting and settlement module 34; 



business procedure definition module 36; and 
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channels matrix management module 38. 
Host Server 12 

The host server 12 operates to provide message brokering services between 
part,cipants involved in an exchange of messages. As such, the host server 12 is 
in data communication with the at least one transaction device 14 service 
provider systems 16, databases 18, process designer 20 and content 
management system 22. The host server 12 further comprises: 

• adaptors 40; 

• process automation engine ("PAE") 42; 
10 * electronic inventory 44; and 

• monitoring system 46. 
Adaptors 40 

Adaptors 40 can be classified as front-end adaptors 40a and back-end adaptors 
40b. Front-end adaptors 40a are responsible for data communication with 
15 transaction devices 14. Back-end adaptors 40b are responsible for data 
communication with service provider systems 16. In other respects, front-end 
adaptors 40a and back-end adaptors 40b are basically identical. 

Each adaptor 40 has an associated relationship. In the context of the functions of 
an adaptor 40, a relationship represents data necessary for transforming 
20 messages received by the adaptor 40 from a format native to the adaptor's 40 
associated transaction device 14 or service provider system 16, into a format 
native to the PAE 42 and vice versa. Thus, by reason of its associated 
relationship, the adaptor 40 is operable to act as a translator. 
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Adaptors 40 "listen" for transaction messages from its respective transaction 
device 14 or service provider system 16, as appropriate. On receipt of a 
transaction message, the adaptor 40 operates to transform the message in 
accordance with its associated relationship for forwarding to the PAE 42. 
5 Similarly, on receipt of a message from the PAE 42, the adaptor 40 operates to 
transform the message in accordance with its associated relationship for 
forwarding to its respective transaction device 14 or service provider system 16, 
as appropriate. 

PAE 42 

10 The PAE 42 is not a single component, but a logical concept comprising: 



15 



at least one process model 48; 



message buses 62; 



a message receiver 64; 



at least one request handler 66; 



a retry receiver 68; and 



at least one process executor 70. 



Process Model 48 



Process model 48 is, as described in more detail below, a programmatic 
representation of a business procedure. However, a process model 48 is able to 
20 represent any short-duration process that needs to happen repeatedly in a 
predictable manner. 
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Message buses 62 are used for communicating messages internally between 
electronic transaction system 10 components. Message buses 62 work on a 
publish/subscribe arrangement. Messages are published by various components 
to the desired message bus 62. Such messages may include extra information. 

The various components subscribe to the desired message bus 62 in order to 
receive messages. Subscription requires the component to specify subscription 
criteria. Thus, on a message being published to the message bus 62, the 
message bus checks the message against the various subscription criteria of its 
subscribers. Where the message matches the subscription criteria of a 
subscriber, the subscriber is notified of the publication of the message to the 
message bus 62. 

In the embodiment being described there are four message buses 62 - inbound 
message bus 62a; outbound message bus 62b; retry message bus 62c; and 
15 response message bus 62d. 

Message Receiver 64 

Message receiver 64 subscribes to inbound message bus 62a. When notified of 
the existence of a message, the message receiver 64 operates to decode the 
message. This is done with reference to the relationship associated with the 
20 adaptor 40 through which the message has been received. In this manner, while 
in the context of translation by an adaptor 40, the relationship is agnostic as to the 
content of the message, in the context of processing of the message for the 
purposes of the message receiver 64, the relationship may also be interested in 
the content of the message. 

25 Once decoded, the message receiver 64 operates to determine whether the 
message is a client request or a service response. In this regard, if the message 
includes correlation information, the message received 64 designates the 
message a service response and operates accordingly (refer to the examples 
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below). If the message does not include correlation information, the message 
receiver 64 assumes that the message is a client request, ie any request for an 
electronic good or service from a transaction device 14. (Note that in some 
instances the message receiver 64 may be able to determine that a message is a 
5 service response by nature of the format of the message, even in the absence of 
correlation information). Client requests are then forwarded to request handler 
66. 

Request Handler fifi 

Each relationship has an associated request handler 66. On receipt of a client 
10 request, the request handler 66 either processes the client request itself or 
identifies .the appropriate process model that the process executor 70 executes 
In the latter arrangement, the request handler 66 forwards the client request to the 
process executor 70. 

Retry Receiver 68 

15 Retry receiver 68 is a subscriber to the retry message bus 62c. The functions of 
the retry receiver are described in more detail in the examples below. 

Process Exftrutnr 7n 

The process executor 70 executes the process model 48 as determined by 
request handler 66. To some extent, however, the process model 48 is self- 
20 executing. The client request provides the initial data upon which the process 
model 48 operates. 

Electronic Inventory 44 

The electronic inventory 44 is used to store activated electronic goods The 
electronic goods may, amongst others, take the form of movie pass numbers 
25 recharge codes for telecommunications carriers or software. 
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Electronic goods in the electronic inventory 44 are serialised and are often 
represented by a 'P.N'. The PIN is a unique number the servioe provider uses to 
■dentrfy a purchased eieotronic good. Typioally, the P,N is encrypted and is kept 
pnvate until the time of issue. P 

5 PINs cannot be issued twice. An elecfronic good in the eiectronic inventory 44 

Z a be p| U N Sed ° nly ° nCe - T ° ' hiS end ' *• inventory 44 must guarantee 

that a pin ,s issued at most once (subject to the following exception). 

Electronic goods are typically supplied as a data file containing serialised 'PINs' 

10 theV I 7 be,B 3 traCkin9 meChaniSm f ° r P ' NS ' the PINs « ^ely 
10 he delrvered g00 d. The need to allocate a serial number to each stock „em is 

necessary for supplier relationship purposes. The serial numbers are a public 

~r of the elecfronic good and can be used for reconciliation and plem 

If an electronic good is returned, it is put in escrow for a predetermined period of 
15 me and may be reconciled with the supplier to determine if I, was used or no, 
Upon completion of the electronic good's escrow period, the unique etectronic 
good is able to be resold. ironic 

The need to keep the electronic goods in escrow for a predetermined period of 
hme ,s for fraud prevention purposes. When a return o, a successfully delivered 

20 e ectronrc good occurs, the merchant is stil, in possession o, the e,e cLic go* 
and may try to use the electronic good in some way. „ ,he electronic good was 
hen rssued to a customer o, another merchant, who then proceeded to redeem 
.he electron, good after the initial merchant has used the electronic good the 
redempbon would be blocked because of the fraud of the initial merchant 

25 However, by placing the eiectronic good into escmw for a period of time the 
chance of this type of fraud occurring is reduced and/or perpetrators o, this type „ f 
fraud can easily be identified. 

Electronic inventory 44 receives service requests from the PAE 42. 



WO 2005/001725 



PCT/AU2004/000855 



-16- 

Monitoring System 46 

Monitoring system 46 operates on a proactive and reactive level. When operating 
on a proactive level, monitoring system 46 checks key aspects of the operation of 
the host server 12. If this check reveals that one or more alert conditions are 
5 satisfied, an alert is generated. The alert is sent to an appropriate representative 
of the operator of the electronic transaction system 10 by way of e-mail or SMS 
message. 

When operating on a reactive level, the host server 12 may itself issue a problem 
notification to the monitoring system 26. The monitoring system 26 then 
10 generates an alert. Again, the alert is sent to an appropriate representative of the 
operator of the electronic transaction system 10 by way of e-mail or SMS 
message. 

Transaction Device 14 

Each transaction device 14 comprises a processor and memory means. The 
15 processor is operable to execute embedded software stored on the memory 
means. The embedded software comprises a transaction application and a 
payment application. 



The transaction application is similar to a web browser in nature. It downloads 
content from the content management system 22 on a periodic basis. This 
20 downloaded content may include data relating to: 

• a description of the service and/or good to be provided; 

the graphics to be displayed in respect of the service and/or good; 

details of acceptable payment methods for each service and/or good; 

details of acceptable validation or data entry mechanisms for each 
25 service and/or good; 
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• details of any documents) to be provided to the customer on 
successful sale of an electronic service or good. 

• menu structure for navigating the various services and/or goods 
available for purchase; and/or 

5 . details of any security mechanisms implemented to control access to 

any restricted portions of the menu structure. 

As such, the downloaded content is used by the transaction application to 
generate a user interface through which a customer interacts to purchase an 
electronic service or good. The concept of the user interface is important, as it 
1 0 provides functionality akin to a normal EFTPOS transaction. 

The use of downloaded content as the means of developing the user interface 
means that the transaction application does not change when a new electronic 
service or good is to be added to the electronic transaction system 10. As a 
result, there is also no need for the transaction application to be recertified. 

15 As discussed above, the downloaded content may include authentication, data 
entry and document detail information. As a result, the transaction application 
must also be capable of controlling a printer, card reader or other peripheral 
device connected to, or integrated into, the transaction device 14. 

The payment application is typically an EFTPOS payment application. However, 
20 any payment application capable of processing payment from a customer may be 
used. The payment application is separate from the transaction application. The 
payment application and transaction application can communicate though by 
means of an application programming interface. In this manner, the transaction 
application does not interfere with the functionality of the payment application. 

25 This is also important as it means that security concerns regarding payment 
processing are separated from security concerns regarding transaction 
processing. 
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Each transaction device 14 is associated with a merchant. 
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Service Provider Systems 16 

Service provider systems 16 represent the computer systems associated with the 
various suppliers of the electronic services and goods. Each service provider 
system 16 is in data communication with the host server 12. The processing 
performed by each service provider system 16 is beyond the scope of the present 
invention and therefore the service provider systems 16 will not be described in 
further detail. 



Databases 18 



10 Databases 18 comprise an administration database 18a, a transaction database 
18b and a reporting database 18c. Administration database 18a stores 
information relating to the at least one transaction device 14 and the merchant 
associated with each transaction device 14. Transaction database 18b holds 
information on each transaction processed by the electronic transaction system 

15 10. Reporting database 18c holds the same information as held in administration 
database 18a and transaction database 18b, but in a simplified form, particularly 
optimised for reporting. In this manner, the transaction database 18b is also 
relieved of some processing load. 

As information is constantly being written to the databases 18, and the timing and 
20 type of information to be written to the databases 18 would be known to the 
person skilled in the art, specific instances will not be described herein. 

Process Desjfl nergO 

Process designer 20 is used to create the process model 48. While the process 
model 48 is computer software, conceptually, a process model 48 consists of a 
25 series of steps 50 and links 52. 
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As shown in Figure 2, the position of each link 52 provides direction as to the next 
step 50 to execute based on the outcome of the present step 50. To elaborate 
links 52 that connect to the top of the step 50 represent the connection from a 
parent step 50 (ie. the step 50 that has just finished processing). Links 52 that 
5 sprout from the left of step 50 represent the connection to a child step 50 that is to 
execute on failure of the current step 50. Links 52 that sprout from the bottom of 
step 50 represent the connection to a child step 50 that is to execute on the 
current step 50 resolving to a value of "FALSE". Links 52 that sprout from the 
right of step 50 represent the connection to a child step 50 that is to execute on 
the current step 50 resolving to a value of "TRUE". Thus, each step 50 must 
resolve to a Boolean value or fail. 

Multiple links 52 may sprout from the left, right or bottom of a step 50 as a means 
of indicating parallel child steps 50 to be processed on resolution of step 50. 

This uniform structure for process models simplifies processing for delivery of the 
1 5 electronic good or service. 

Content Mana gement System 22 

In essence the content management system 22 controls the construction, release 
and maintenance of content downloaded by transaction devices 14. However, in 
doing so, the content management system 22 references the channels matrix 26 
20 to ensure that any constraints recorded in the channels matrix 26 are not 
contravened. In doing so, this may result in exclusion of part, or all, of the 
content. 

The content management system 22 comprises a user navigation designer 54 a 
document designer 56, a channel groupings module 58 and a content download 
25 management module 60. 

The user navigation designer 54 allows for creation of a menu system ultimately 
replicated on the transaction device 14 following content download. It also allows 
a party to designate in what manner the customer is required to interact with the 
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transaction device 14 in order to purchase the specified goods and/or services. 
For example, using the user navigation designer 54 anyone may specify what 
information, if any, is to be obtained by means of magnetic swipe card or an 
external keyboard, for example, information in respect of the customer's account 
5 number. 

The document designer 56 facilitates the graphical design of documents to be 
printed by the transaction device 14. The designed documents form part of the 
content. Ideally, document designer 56 is used to produce receipts to be issued 
to customers upon completion of a successful transaction. 

10 Channel grouping module 58 facilitates allocation of a transaction device 14 to a 
channel grouping. A channel grouping represents a collection of transaction 
devices 14 that are to receive the same content. 

Each transaction device 14 can belong to one or more channel groupings. A 
transaction device 14 can have its channel grouping changed or have a channel 
15 grouping added at any time. 

Content download management module 60 facilitates the scheduling of 
downloads for particular transaction devices 14 or channel groupings. In this 
context, the content download management module 60 notifies each transaction 
device 14 of its scheduled time to download content. The transaction device 60 
20 then contacts the host server 12 at the scheduled time to initiate the content 
download. 

The content download management module 60 also manages the reporting of the 
success or failure of a scheduled download, as appropriate. 

Scheduler 24 and Schedule Management Module 28 



Scheduler 24 and schedule management module 28 combined operate to 
manage any scheduled task, other than content download. One scheduled task 
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handled by the scheduler 24 and schedule management module 28 is the periodic 
transmission of a transaction listing to service provider systems 16. 



The channels matrix 26 is central to controlling whether a merchant can sell a 
5 product, and if so, for what price, and at what commission. The channels matrix 
26 is also used during transaction processing to ensure that the rules 
implemented therein are always satisfied. To elaborate, if the content of a 
transaction device 14 is somehow out-of-date, the channels matrix 26 may 
d.sallow a sale of a product if it is being sold for an incorrect price. 

10 Channels matrix management module 38 manages the channels matrix 26 
Channels matrix 26 is a multi-dimensional matrix used to control the electronic 
services and/or goods available for sale by each transaction device 14, channel 
grouping or merchant. Factors covered by the channels matrix 26 include: 

• availability; 
15 • pricing; and 



• merchant margin (ie. commission). 

In this manner, the availability and price of an electronic service or good may be 
adjusted based on such factors as the locality of, or industry segment of the 
merchant associated with, the transaction device 14. The channels matrix 26- 
20 further allows for business rules, such as "merchants in industry X, belonging to 
bank Y, cannot sell electronic service Z after date D", to be implemented - each 
business rule having a predetermined lifespan. 

The dimensions of the channels matrix 26 are composed of attributes of the 
dev.ce, the merchant and the electronic good or service. An example of a device 
25 attribute is 'Location'; an example of a merchant attribute is 'Retailer Group'; and 
an example of an electronic good or service is 'Brand'. Implemented business 
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rules are made by combining attributes of merchants and devices and e,ec,ronic 
goods or services. ironic 

Business rules are cumuiative. „ more man a single ru.e appiies to a device for 
merchant margin or price than an aigorithm is used to establish the most 'relevant' 
5 rule. Th,safcor,«hm is basdd on a weighting va,ue scheme between attributes. 

Merchant Rgegr ting Morii.i. in 

The movant reporting module 30 allows merchants and other operators of 
transaction devices 14 ,o access a series of secure reporting screens Each 

10 ZTtZTJT de,ai ' S ° f ' ranSaC,i0nS " reC ° rded «"* database 
18c or deta,ls of fransacons presently being processed by the PAE 42 The 

transaction de.ai,s may be provided as dn„ down graphs or summaries as desired 
by the merchant or operator, as appropriate. 

Management Mgdjjlg 33 

Management module 32 allows for a transaction device 14 or service provider 
15 system 16 «o be deciared inactive. When a transaclion device 14 is de ,a ed 

STu Z se ™ 12 is not ab,e to rece,ve '~ ns f ™ - <~ 

selr 2 ia T k, S6n " Ce Pr0Vider SYStem 16 ' S dedared «» "~ 

se.er ,2 ,s no, able ,o process any transactions requesting purchase of an 

. ec,ron,c sendee or good provided by the merchant associated wtth me service 
20 provider system 16. *civice 

The management module 32 also manages information in respect of each 

££T T 14, mercham ' supp,ier ' channel ' indusb * « ^ 

global mformatton made use of by ,he eiectronic transaction system 10. 

Accounting ,M c.» t| emen , ^,,1. ,„ 

25 Accounting and settlement module 34 performs pracedures ,ha, provide for 
setttemen, between a merchant and ,he operator of Ihe efcettonic l£Z 



WO 2005/001725 

PCT/AU2004/000855 

-23- 

system 10. This is required because the operator of the electronic transaction 
system 10 is not an acquirer of the financial transaction (transactions processed 
by the transaction device 14 accruing to the merchant who made the sale). 

Business Procedure D efinition Module ™ 

5 The business procedure definition module 36 facilitates the definition of 
repeatable business processes, such as 'release a new product' or 'change the 
merchant margin for channel X'. Often there are many repeatable business 
processes surrounding the brokering of electronic goods or services A 
repeatable business procedure helps to maintain quality and consistency within 
1 0 the electronic transaction system 1 0. 

Business procedures are stored in the administration database 18a. 

The invention will now be described in the context of two examples of its expected 
use, with additional components being described as necessary. As the two 
examples have a common setup procedure, this setup procedure is described 
15 first. 

Using process designer 20, an administrator of the electronic transaction system 
10 creates at least one process model 48. Each process model 48 is 
representative of the processing subsequently to occur by the PAE 42 on receipt 
of an appropriate client request. 

20 The administrator also checks the level of stock in the electronic inventory 44 If 
the level of stock is low, a request for more stock is made to the appropriate 
supplier. 

The supplier then provides the stock in the form of an encrypted file of 
predetermined format. Ideally, the stock recorded in the encrypted file is delivered 
25 ,n an "inactive" state. In this manner, the stock cannot be used by another party 
who may receive the encrypted file by mistake. Upon successful decryption of the 
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file, the administrator confirms receipt of the file with the supplier. In turn, the 
supplier operates to activate the stock recorded in the encrypted file. 

At roughly the same time, the administrator or a merchant generates content 
relating to the proposed delivery of an electronic good or service using the content 
5 management system 22. The content management system 22 only allows 
content to be generated that conforms with the constraints recorded in the 
channels matrix 26. The administrator or merchant may also act to allocate, or 
amend allocations of, transaction devices 14 to channel groupings as may' be 
necessary for appropriate delivery of the electronic good or service. 

10 Once the administrator or merchant has completed generating the desired 
content, the content download management module 60 communicates with the 
transaction device 14 via the intermediate router. The communication informs the 
transaction device of the scheduled time that it should contact host server 12 to 
download content - in this situation, the new content generated by the 

1 5 administrator or merchant, as appropriate. 

The payment device 14, at the scheduled time, then operates to contact host 
server 12, through an intermediate router (discussed in more detail below). In 
response, host server 12 sends to the payment device 14 - again, via the 
intermediate router - a set of file names with associated cyclical redundancy 
20 check (CRC) numbers. 



25 



30 



Each file name and CRC number represents a component of the content to be 
downloaded to memory. However, as the transaction device 14 is a low- 
bandwidth device, a comparison is first made between each filename and CRC 
number in the set of file names and CRC numbers and the file names and CRC 
numbers associated with components of content already downloaded. Only in 
instances where a file name and CRC number in the set of file name and CRC 
numbers does not match a file name and CRC number associated with 
components of content already downloaded does the transaction device 14 
operate to download to memory the components of content having the non- 
matching file name and CRC numbers from content management system 22. 
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Those components of content already downloaded that have an associated file 
name and CRC number that does not match a file name and CRC number in the 
set of file names and CRC numbers are deleted from memory. In this manner, 
the file name and CRC numbers of components of the content stored in memory 
5 always exactly match the file names and CRC numbers in the set of file names 
and CRC numbers received from host server 12. 

The content stored in memory is then used by the transaction application to 
generate a user interface through which a customer interacts to purchase an 
electronic service or good. 

10 Once a customer's selection of a transaction has been completed using the user 
interface, the transaction device 14 operates a modem that forms part of the 
transaction device 14. The modem, via a telecommunications network to which it 
is connected, forms a connection with the intermediate router. 

Intermediate router has dedicated connections to both a payments host and host 
15 server 12. In this manner, both service- and payment-related transactions can 
occur within the scope of a single call. The intermediate router firstly attends to 
the payment-related transaction by forwarding the transaction to the payments 
host. On successfully transacting payment, the payments host sends an 
authorisation response back to the intermediate router. The intermediate router 
20 forwards the authorisation response to the transaction device 14. 

The intermediate router then forwards the service related transaction to host 
server 12 who treats the transaction as a client request. Host server 12 receives 
the client request at adaptor 40a. 

The adaptor 40a then publishes the request to inbound message bus 62a along 
25 with message context information. The message context information indicates any 
errors that occurred during delivery as well as any other information the adaptor 
40a may include. The message context information will often include an identifier 
the adaptor 40a can use as a correlation key. This is the first correlation key. 
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The adaptor 40a then awaits a response from the PAE 42 regarding the request. 
To receive such a response, adaptor 40a subscribes to outbound message bus 
62b for messages published by the PAE 42 including the first correlation key. 

Message receiver 64 also has a subscription to inbound message bus 62a. Its 
5 subscription is for all new client requests. Thus, on publication of the request, 
inbound message bus 62a notifies message receiver 64 of the existence of the 
request. The message receiver 64 then retrieves the request from the inbound 
message bus 62a. 

As the message retrieved from the inbound message bus 62a is unknown to the 
10 message receiver 64, message receiver 64 initially treats the message as a client 
request. However, the message receiver 64 thereafter decodes the message 
using the relationship associated with adaptor 40a. Once decoded, and as 
mentioned above, the message receiver 64 operates to determine the type of 
message by reference to: 

15 • the inclusion or omission of a correlation key; and/or 

• the format of the message. 

In this example, as message receiver 64 resolves the message to be a client 
request, the message is passed to request handler 66. 

Request handler 66 processes the message to determine the appropriate process 
20 model 48 to use to execute the client request. Once the appropriate process 
model 48 has been determined, control is passed to process executor 70 to 
execute the process model 48. Typically, for electronic services a 'service master 
process model' will be used. Within this services master process model, specific 
processing will be performed for a particular electronic service by identifying the 
25 requested 'service ID' in the client request message. Each service ID will have a 
process model 48 associated with it and the service master process model will 
execute this service specific process model 48 as a sub-process. 
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lt is at this point that the examples differ. 

In this, the first example, process model 48 includes an asynchronous service 
request and then a synchronous service request. Processing executes as norma, 
until the asynchronous service request is reached. 



5 In executing the process model 48, process executor 70 subscribes to response 
message bus 62d in order to properly process the asynchronous service request 
The subscription is based on a second correlation key. 

As the asynchronous service request is to be issued to service provider system 
16, ,t ,s necessary for the process executor 70 to encode the asynchronous 
10 service request. Encoding is made in accordance with the relationship associated 
w,th adaptor 40b, itself associated with service provider system 16. The encoded 
asynchronous service request is then published to outbound message bus 62b 
The encoded asynchronous service request includes the second correlation key. 

Processing of the process model 48, then proceeds as per normal. 

15 Adaptor 40b is also a subscriber to outbound message bus 62b. Adaptor 40b 
subscribes on the basis of the services that it offers (which necessariiy need to be 
.ncorporated into encoded asynchronous service request message). Accordingly 
on publication of the encoded asynchronous service request message, outbound 
message bus 62b notifies adaptor 40b of the publication of the encoded 

20 asynchronous request message. Adaptor 40b then retrieves the encoded 
asynchronous request message from the outbound message bus 62b. 

The encoded asynchronous service request message is then sent to service 
provider system 16. 

The seivice provider system 16 then processes the asynchronous service request 
25 message to generate a service response. Service response is then sent by the 
service provider system 16 to adaptor 40b. Service response includes the second 
correlation key. 



5 
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The adaptor 40b then publishes the service response to inbound message bus 
62a along with message context information. The message context information 
.nd.cates any errors that occurred during delivery and/or transformation The 
published form of the service response includes the second correlation key. 

On publication of the service response, inbound message bus 62a notifies 
message receiver 64 of the existence of the service response. The message 
rece.ver 64 then retrieves the service response from the inbound message bus 
62a and decodes the message using the relationship associated with adaptor 

10 On ana.ysis of the decoded service response, the message receiver 64 confirms 
the message to be a service response by virtue of the existence of the second 
correlation key. The decoded service response is then published to response 
message bus 62d with its second correlation key. 

Process executor 70 is then informed of the publication of the decoded service 
15 response by response message bus 62d and retrieves the decoded service 
response from the response message bus 62d. The decoded service response is 
then used in further processing of the process model 48 as may be required. 

Processing of the process model 48 then proceeds until it reaches the 
synchronous service request 

20 Again, as the synchronous service request is to be issued to service provider 
system 16, it is necessary for the process executor 70 to encode the synchronous 
serv.ce request. Encoding is made in accordance with the relationship associated 
w,th adaptor 40b, itself associated with se,vice provider system 16. The encoded 
synchronous service request is then published to outbound message bus 62b 

25 along with message context information. 

At this stage, further processing of the process model 48 by the PAE 42 is then 
halted pending return of a service response by service provider system 16. 
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On publication of the encoded synchronous service request message, outbound 
message bus 62b notifies adaptor 40b of the publication of the encoded 
synchronous request message. Adaptor 40b then retrieves the encoded 
synchronous request message from the outbound message bus 62b and its 
5 message context information. 

The encoded synchronous service request message is then sent to service 
provider system 16. 

The service provider system 16 then processes the synchronous service request 
message to generate a service response. Service response is then sent by the 
1 0 service provider system 16 to adaptor 40b. 

The adaptor 40b then publishes the service response to inbound message bus 
62a along with message context information. The message context information 
indicates any errors that occurred during delivery as well as any other information 
the adaptor 40b may include. 

15 On publication of the service response, inbound message bus 62a notifies 
message receiver 64 of the existence of the service response. The message 
receiver 64 then retrieves the service response from the inbound message bus 
62a and decodes the message using the relationship associated with adaptor 



20 The decoded service response message is then treated by the message receiver 
64 as a response to its service request and publishes the decoded service 
response to response message bus 62d. This correlation is made possible by the 
blocking of further processing of the process model 48 as described above. 

Process executor 70 is then informed of the publication of decoded service 
25 response by response message bus 62d and retrieves the decoded service 
response from the response message bus. The decoded service response is 
then used in further processing of the process model 48. 
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lf, for any reason, it is not possible to process a client request, the client request 
may be published to retry message bus 62c. Retry receiver 68 is a subscriber to 
the retry message bus 62c. Operation of the retry receiver 68 is similar to 
message receiver 66. However, retry receiver's 68 subscription to retry message 
5 bus 62c allows for client requests to remain published on the retry message bus 
62c for a set period of time before being retrieved. 

In this, the second example, process model 48 operates to issue an electronic 
good from electronic inventory 44. 

When process model 48 reaches a request for an electronic good to be issued 
10 from electronic inventory 44. it issues a service request to the electronic inventory 
44. In this manner, for the purposes of dealing with service requests the 
electronic inventory 44 is treated the same as a service provider system 16 even 
though it is an internal component of the host server 12. 

Electronic inventory 44 receives a service request from the PAE 42 (as initiated by 
15 process model 48). On receipt of the service request, the electronic inventory 44 
checks the service request for a service ID. The electronic inventory 44 then 
checks for an electronic good having the same service ID. Upon identifying a 
corresponding electronic good having the same service ID, the electronic 
inventory 44 operates to issue the electronic good to transaction device 14. 

20 At this point, processing of both the first and second examples conform. 
Accordingly, the description hereafter relates to both examples. 

Following execution of a process model 48, a client response message is 
generated indicating the success or failure of the client request, as appropriate 
Accordingly, process executor 70 subscribes to inbound message bus 62a in 
25 order to ensure that the service response is actually received by the transaction 
device 14 that issued the service request. The subscription is based on a third 
correlation key. 
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The processor executor 70 thereafter encodes the client response message in 
accordance with the relationship associated with adaptor 40a. The encoded client 
response is then published to outbound message bus 62b along with all message 
context information that was received in the client request message. Thus, the 
5 encoded client response includes the first correlation key as well as a new third 
correlation key. 

Adaptor 40a is also a subscriber to outbound message bus 62b. Adaptor 40a 
subscribes on the basis of the first correlation key. Accordingly, on publication of 
the encoded client response message, outbound message bus 62b notifies 

10 adaptor 40a of the publication of the encoded client response message. Adaptor 
40a then retrieves the encoded client response message from the outbound 
message bus 62b. Adaptor 40a then operates to determine the client request that 
the encoded client response corresponds with by means of the first correlation 
key. Thereafter, the encoded client response is sent as a message to the 

15 intermediate router. 

The intermediate router then forwards the client response message to the 
transaction device 14. if the client response message indicates that the client 
request was unsuccessful, the transaction device 14 sends a payment reversal 
request to the payment host via the intermediate router. 

20 In either case, the adaptor 40a operates to send a delivery confirmation message 
to the PAE 42. The delivery confirmation message includes the third correlation 
key. The delivery confirmation message confirms with the PAE 42 that the 
response has been delivered to the appropriate transaction device 14. 

The adaptor 40a then publishes the delivery confirmation message to inbound 
25 message bus 62a. 

On publication of the delivery confirmation message, inbound message bus 62a 
notifies process executor 70. Process executor 70 then retrieves the delivery 
confirmation message from the inbound message bus 62a. 
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If no delivery confirmation message is received within a predetermined time 
period, process executor 70 treats the delivery as a failure. On failure of a 
delivery, roll-back commands are processed to reverse the processing performed 
by the PAE 42 in executing the process model 48 to which the failed delivery 
5 relates. This may include sending roll-back commands to service provider 
systems 16. 

From the point of view of a transaction device 14, this is shown graphically at 
Figure 4. 

It should be appreciated by the person skilled in the art that the invention is not 
10 limited to the examples described. In particular, the following additions and/or 
modifications can be made without departing from the scope of the invention: 

• the user interface generated by the transaction application may 
operate to receive input by means of an integrated keypad of the 
transaction device 14. Alternatively, input may be provided by means 

15 of a touchscreen through which the user interface is also displayed. 

Authorisation procedures can be implemented where multiple, 
unrelated merchants or operators use the same electronic 
transaction system 10. In such an arrangement, transaction details 
may be filtered such that details only relevant to the merchant or 
20 operator are shown. 

• Front-end adaptors 40a may be modified to provide means for 
confirming the identity of a transaction device 14 from which it 
receives a transaction message. If the identity of a transaction 
device 14 can not be confirmed, the transaction message will be left 

25 t0 timeout on the assumption that the transaction message 

represents an attempted breach of security. Additionally, checks 
may be made against the capacity of a transaction device 14. In this 
manner, the host server 12 can seek to ignore transaction devices 14 
that may be externally controlled as part of a denial of service attack. 
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Adaptors 40 may be in permanent communication with its associated 
transaction device 14 or associated service provider system 16, as 
appropriate. If communicating via TCP/IP this may be by means of a 
single socket. 

The transaction device 14 may be adapted to include removable, 
writeable media, such as a memory stick, floppy disk, compact disc 
or digital video disc. In this manner, the transaction device 14 can 
record an electronic good, or document, on the writeable media 
which the customer can then take away with them. 

Transaction device 14, via intermediate router, may operate to obtain 
a pre-authorisation indication from , the payments host rather than 
actually transacting a payment. Accordingly, if the service response 
indicates that the service request was unsuccessful, a reversal 
payment request need not be made. However, if the service 
response indicates that the service request was successful, 
confirmation of payment can then be made by the payments host in 
response to a request issued by the transaction device 14, via the 
intermediate router,. 

In a further arrangement, transaction device 14 may omit the 
payment application. In such an arrangement, intermediate host may 
also be omitted, a modem or other communications device integrated 
into the transaction device 14 operable to establish a direct 
connection with host server 12. Alternatively, transaction device 14 
may incorporate one or more applications in addition to the payment 
and transaction applications. In this arrangement, as illustrated in 
Figure 5, such applications may be managed by a multi-application 
manager module so as to property control access to resources, such 
as the modem and screen, by each application. Thus, payment can 
be made by way of a standard payment application, or a non- 
standard payment application, such as a loyalty point payment 
application. 
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All transmissions to and from host server 12 may be encrypted. 
Ideally, any encryption technique used meets the encryption 
standards set for financial institutions. 

• While the transaction device 14 has been described as including a 
5 modem for communication with the intermediate router/host server 

12, it should be appreciated by the person skilled in the art that any 
communication means may be used. Yet further, the transaction 
device 14 may be in direct connection with the intermediate 
router/host server 12, as appropriate, in which case the 
communication means takes the form of communications software 
stored in the memory of the transaction device 14. 

Process model 48 may be arranged such that steps 50 may resolve 
to a fail value and values other than Boolean values. 

• Message buses 62 may implement messaging mechanisms other 

15 than tne Publish/subscribe mechanism referred to herein. For 

example, direct communication or "blackboard"-like messaging 
arrangements may be used. 

Electronic inventory 44 may be adapted to dispense electronic goods 
of a single type. In such an arrangement, serial IDs may be omitted. 
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The transaction device 14 need not be a dedicated device with 
embedded software. The transaction device 14 may actually be a 
personal computer or an integrated cash register. 

Content need not be scheduled for download at specified times but 
may be downloaded on creation. In this manner, content can be 
provided to the transaction devices 14 on an almost "real-time" basis 
following its creation via the content management system 22. 



